1. Field of the Invention
The present invention relates to computer communications, and deals more particularly with a technique, system, and computer program for providing a lightweight, system-independent and language-independent communications object model for use with TCP/IP communications. This model encapsulates low-level socket functions, and provides support for both synchronous and asynchronous input/output.
2. Description of the Related Art
The TCP/IP protocol (Transmission Control Protocol/Internet Protocol) is the de facto standard method of transmitting data over networks, and is widely used in Internet transmissions. TCP/IP uses the concept of a connection between two xe2x80x9csocketsxe2x80x9d for exchanging data between two computers, where a socket is comprised of an address identifying one of the computers, and a port number that identifies a particular service, or process, on that computer. The process identified by the port number is the process that will receive the incoming data for that socket. A socket is typically implemented as a queue by each of the two computers using the connection, whereby the computer sending data on the connection queues the data it creates for transmission, and the computer receiving data on the connection queues arriving data prior to processing that data.
TCP/IP is typically used in a client-server model of computing, where the machine at which the user requests information is referred to as the client, and the computer that locates the information and returns it to the client is the server. In the World Wide Web environment, the server is commonly referred to as a xe2x80x9cWeb serverxe2x80x9d. The client-server model may be extended to what is referred to as a xe2x80x9cthree-tier architecturexe2x80x9d. This architecture places the Web server in the middle tier, where the added tier typically represents databases of information that may be accessed by the Web server as part of the task of processing the client""s request. This three-tiered architecture recognizes the fact that many client requests are not simply for the location and return of static data, but require an application program to perform processing of the client""s request in order to dynamically create the data to be returned. In this architecture, the Web server may equivalently be referred to as an xe2x80x9capplication serverxe2x80x9d.
In order to exchange data across a network or Internet, a computer may act as a client, a server, or both, depending on the application running on the computer. Some communication functions are used only for the client role, other functions are used only for the server role, and yet others are used in both roles.
Establishing and maintaining end-to-end communications through one or more networks is an extremely complicated process. To insulate a programmer writing application software that will run in this environment from the underlying communication details, a number of vendors have developed prepackaged communications software with an interface that is accessible to an application program. These packages may alternatively be referred to as xe2x80x9clibrariesxe2x80x9d. An example is Windows Sockets, or xe2x80x9cWinsockxe2x80x9d, from Microsoft Corporation. Winsock contains functionality to implement socket-based communications using TCP/IP on a computer running a Windows operating system. These communications functions are made available to the programmer through an Application Programming Interface (xe2x80x9cAPIxe2x80x9d). The programmer then invokes selected functionality from this package by coding a reference to the corresponding API in his application program. For a computer running the UNIX operating system, the Berkeley Software Distribution (xe2x80x9cBSDxe2x80x9d) sockets programming interface is commonly used. In the object-oriented environment, a communications package referred to as xe2x80x9cjava.netxe2x80x9d has been produced by Sun Microsystems for use with the Java programming language. (xe2x80x9cJavaxe2x80x9d is a trademark of Sun Microsystems, Inc.) xe2x80x9cjava.netxe2x80x9d is a class of communications methods for use with sockets-based connections.
These packages of communications functionality have been developed for specific operating systems, and for use with specific programming languages. xe2x80x9cjava.netxe2x80x9d, for example, is only usable from application programs written in the Java language. The commands (that is, the syntax with which a programmer requests communication functionality) in the Winsock API differ from the commands available in the BSD API. This difference is due (at least in part) to tailoring the implementations to run on particular operating systems. For example, while the BSD API includes a xe2x80x9cclosexe2x80x9d command, the corresponding Winsock API command is xe2x80x9cclosesocketxe2x80x9d. Further, the differences between the BSD and Winsock API support for asynchronous input/output (xe2x80x9cI/Oxe2x80x9d) function significantly impacts the design of applications utilizing this function, such that a restructuring of the application is required in order to port from one operating system to another. Java itself does not provide support for asynchronous I/O. With the proliferation of low-end handheld and embedded devices, the cost of porting application designs to varied devices becomes more and more expensive.
In addition, the data structures used in the various libraries are not consistent, so that an application program compiled for one library cannot be executed on a machine where the underlying function is supplied by a different library implementation. The particular programming model around which an operating system is designed is also a factor in differing implementations within libraries. For example, in addition to the differences in asynchronous I/O discussed above, some versions of the Windows operating system use non-preemptive scheduling, while other operating systems use preemptive scheduling. The details of this distinction are beyond the scope of this discussion, but the significance of the distinction is that server functionality ( for example, the xe2x80x9cblocking receivexe2x80x9d function) must be implemented differently to properly accommodate each approach. Furthermore, some libraries provide rich functionality, while others are limited to basic requirements.
Further, an xe2x80x9call-or-nothingxe2x80x9d approach to using a specific library is required. As devices capable of communicating over networks become smaller and smaller, the need for efficient and compact communications software becomes increasingly important. Handheld computers and other embedded devices, such as the PalmPilot, have limited memory and storage capacity, and may use specialized or device-specific operating systems for which no library of communications functionality is readily available. Such computers need access to a library providing basic communications functionality, without the overhead associated with advanced communications. (xe2x80x9cPalmPilotxe2x80x9d is a trademark of 3Com Corporation.)
For an application programmer, these operating system and programming language dependencies and differences mean that either one version of his application will be created, for a particular operating system or language (restricting the market for his software), or that he must implement different executable versions of the application for each operating system and programming language environment (with a corresponding increase in the cost and effort required for development and support).
Accordingly, a need exists for a technique by which these disadvantages in the current implementations of socket functionality can be overcome. The proposed technique defines a lightweight uniform communications model to encapsulate this functionality. The model is system and language-independent, and supports both synchronous and asynchronous I/O. The functionality included in this model is based on the common denominator of functions provided in modem operating systems, which provide the capability for basic sockets support as well as support for threads.
An object of the present invention is to provide a technique for encapsulating low-level socket functionality.
Another object of the present invention is to provide a technique whereby this functionality is system- and language-independent.
It is another object of the present invention to provide a technique whereby this functionality supports both synchronous and asynchronous I/O.
It is a further object of the present invention to provide a technique whereby this functionality is lightweight and modular, enabling its use within devices having limited memory and storage capability.
It is yet another object of the present invention to provide a communications object model that provides uniform communications functionality which can be implemented in, and ported across, environments ranging from resource-constrained devices through servers.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a system, method, and computer-readable code implementing a software process for use in a computing environment having a connection to a network, for encapsulating socket functionality in a lightweight uniform communications object model. This comprises a plurality of supplied user-invocable communications functions, each of the functions having a defined interface; a subprocess for receiving one or more invocations of any of the defined interfaces; and a subprocess for processing one or more logic routines in response to each of the invocations. Preferably, these functions are provided in a manner that is system-independent, language-independent, and device-independent; the functions include one or more functions supporting synchronous input/output and one or more functions supporting asynchronous input/output; and the model can be implemented in, and ported across, environments ranging from resource-constrained devices through servers. Preferably, a first of the interfaces enables use of a subprocess for creating a sublayer for client support and a second of the interfaces enables use of a subprocess for creating a sublayer for server support; a third of the interfaces enables use of a subprocess for creating one or more data brokers, wherein each of the data brokers may operate on a stream of data or on one or more logical records of data; a fourth of the interfaces enables use of a subprocess for creating one or more data broker assimilators, wherein each of the data broker assimilators assimilates one or more data brokers; a fifth of the interfaces enables use of a subprocess for creating one or more data assimilators, wherein each of the data assimilators provides a subprocess for data assimilation and provides a subprocess for notification of connection termination; a sixth of the interfaces enables use of a subprocess for creating one or more multiplexed data assimilators, wherein each of the multiplexed data assimilators provides a subprocess for data assimilation for data arriving on more than one connection, and provides a subprocess for notification of connection termination of the more than one connection.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.